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Abstract 


The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard 
mechanism for support of multiple authentication methods. This document specifies the use of 
EAP-TLS with TLS 1.3 while remaining backwards compatible with existing implementations of 
EAP-TLS. TLS 1.3 provides significantly improved security and privacy, and reduced latency when 
compared to earlier versions of TLS. EAP-TLS with TLS 1.3 (EAP-TLS 1.3) further improves security 
and privacy by always providing forward secrecy, never disclosing the peer identity, and by 
mandating use of revocation checking when compared to EAP-TLS with earlier versions of TLS. 
This document also provides guidance on authentication, authorization, and resumption for EAP- 
TLS in general (regardless of the underlying TLS version used). This document updates RFC 5216. 


Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force (IETF). It represents the 
consensus of the IETF community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Further information on Internet 
Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and howto provide feedback 


on it may be obtained at https://www.rfc-editor.org/info/rfc9190. 


Copyright Notice 


Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights 
reserved. 
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This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 
Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this 
document. Please review these documents carefully, as they describe your rights and restrictions 
with respect to this document. Code Components extracted from this document must include 
Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are 
provided without warranty as described in the Revised BSD License. 
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1. Introduction 


The Extensible Authentication Protocol (EAP), defined in [RFC3748], provides a standard 
mechanism for support of multiple authentication methods. EAP-TLS [RFC5216] specifies an EAP 
authentication method with certificate-based mutual authentication utilizing the TLS handshake 
protocol for cryptographic algorithms and protocol version negotiation and establishment of 
shared secret keying material. EAP-TLS is widely supported for authentication and key 
establishment in IEEE 802.11 [[EEE-802.11] (Wi-Fi) and IEEE 802.1AE [IEEE-802.1AE] (MACsec) 
networks using IEEE 802.1X [IEEE-802.1X] and it's the default mechanism for certificate-based 
authentication in 3GPP 5G [TS.33.501] and MulteFire [MulteFire] networks. Many other EAP 
methods such as Flexible Authentication via Secure Tunneling (EAP-FAST) [RFC4851], Tunneled 
Transport Layer Security (EAP-TTLS) [RFC5281], the Tunnel Extensible Authentication Protocol 
(TEAP) [RFC7170], as well as vendor-specific EAP methods such as the Protected Extensible 
Authentication Protocol (PEAP) [PEAP], depend on TLS and EAP-TLS. 


EAP-TLS [RFC5216] references TLS 1.0 [RFC2246] and TLS 1.1 [RFC4346] but can also work with TLS 
1.2 [RFC5246]. TLS 1.0 and 1.1 are formally deprecated and prohibited from being negotiated or 
used [RFC8996]. Weaknesses found in TLS 1.2 as well as new requirements for security, privacy, 
and reduced latency have led to the specification of TLS 1.3 [RFC8446], which obsoletes TLS 1.2 
[RFC5246]. TLS 1.3 is in large part a complete remodeling of the TLS handshake protocol including 
a different message flow, different handshake messages, different key schedule, different cipher 
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suites, different resumption mechanism, different privacy protection, and different record 
padding. This means that significant parts of the normative text in the previous EAP-TLS 
specification [RFC5216] are not applicable to EAP-TLS with TLS 1.3. Therefore, aspects such as 
resumption, privacy handling, and key derivation need to be appropriately addressed for EAP- 
TLS with TLS 1.3. 


This document updates [RFC5216] to define how to use EAP-TLS with TLS 1.3. When older TLS 
versions are negotiated, RFC 5216 applies to maintain backwards compatibility. However, this 
document does provide additional guidance on authentication, authorization, and resumption 
for EAP-TLS regardless of the underlying TLS version used. This document only describes 
differences compared to [RFC5216]. When EAP-TLS is used with TLS 1.3, some references are 
updated as specified in Appendix A. All message flows are example message flows specific to TLS 
1.3 and do not apply to TLS 1.2. Since EAP-TLS couples the TLS handshake state machine with the 
EAP state machine, it is possible that new versions of TLS will cause incompatibilities that 
introduce failures or security issues if they are not carefully integrated into the EAP-TLS protocol. 
Therefore, implementations MUST limit the maximum TLS version they use to 1.3, unless later 
versions are explicitly enabled by the administrator. 


This document specifies EAP-TLS 1.3 and does not specify how other TLS-based EAP methods use 
TLS 1.3. The specification for how other TLS-based EAP methods use TLS 1.3 is left to other 
documents such as [TLS-EAP-TYPES]. 


In addition to the improved security and privacy offered by TLS 1.3, there are other significant 
benefits of using EAP-TLS with TLS 1.3. Privacy, which in EAP-TLS means that no information 
about the underlying peer identity is disclosed, is mandatory and achieved without any 
additional round trips. Revocation checking is mandatory and simplified with Online Certificate 
Status Protocol (OCSP) stapling, and TLS 1.3 introduces more possibilities to reduce fragmentation 
when compared to earlier versions of TLS. 


1.1. Requirements and Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 
interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


Readers are expected to be familiar with the terms and concepts used in EAP-TLS [RFC5216] and 
TLS [RFC8446]. The term EAP-TLS peer is used for the entity acting as EAP peer and TLS client. The 
term EAP-TLS server is used for the entity acting as EAP server and TLS server. 


This document follows the terminology from [TLS-bis] where the master secret is renamed to the 
main secret and the exporter_master_secret is renamed to the exporter_secret. 
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2. Protocol Overview 


2.1. Overview of the EAP-TLS Conversation 


This section updates Section 2.1 of [RFC5216] by amending it in accordance with the following 
discussion. 


If the TLS implementation correctly implements TLS version negotiation, EAP-TLS will 
automatically leverage that capability. The EAP-TLS implementation needs to know which 
version of TLS was negotiated to correctly support EAP-TLS 1.3 as well as to maintain backward 
compatibility with EAP-TLS 1.2. 


TLS 1.3 changes both the message flow and the handshake messages compared to earlier versions 
of TLS. Therefore, much of Section 2.1 of [RFC5216] does not apply for TLS 1.3. Except for Sections 
2.2 and 5.7, this update applies only when TLS 1.3 is negotiated. When TLS 1.2 is negotiated, then 
[RFC5216] applies. 


TLS 1.3 introduces several new handshake messages including HelloRetryRequest, 
NewsSessionTicket, and KeyUpdate. In general, these messages will be handled by the underlying 
TLS libraries and are not visible to EAP-TLS; however, there are a few things to note: 


e The HelloRetryRequest is used by the server to reject the parameters offered in the ClientHello 
and suggest new parameters. When this message is encountered, it will increase the number 
of round trips used by the protocol. 


e The NewSessionTicket message is used to convey resumption information and is covered in 
Sections 2.1.2 and 2.1.3. 


e The KeyUpdate message is used to update the traffic keys used on a TLS connection. EAP-TLS 
does not encrypt significant amounts of data so this functionality is not needed. 
Implementations SHOULD NOT send this message; however, some TLS libraries may 
automatically generate and process this message. 

e Early Data MUST NOT be used in EAP-TLS. EAP-TLS servers MUST NOT send an early_data 
extension and clients MUST NOT send an EndOfEarlyData message. 

e Post-handshake authentication MUST NOT be used in EAP-TLS. Clients MUST NOT send a 
"post_handshake_auth" extension and Servers MUST NOT request post-handshake client 
authentication. 


After receiving an EAP-Request packet with EAP-Type=EAP-TLS as described in [RFC5216], the 
conversation will continue with the TLS handshake protocol encapsulated in the data fields of 
EAP-Response and EAP-Request packets. When EAP-TLS is used with TLS version 1.3, the 
formatting and processing of the TLS handshake SHALL be done as specified in version 1.3 of TLS. 
This update only lists additional and different requirements, restrictions, and processing 
compared to [RFC8446] and [RFC5216]. 
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2.1.1. Authentication 


This section updates Section 2.1.1 of [RFC5216] by amending it in accordance with the following 
discussion. 


The EAP-TLS server MUST authenticate with a certificate and SHOULD require the EAP-TLS peer to 
authenticate with a certificate. Certificates can be of any type supported by TLS including raw 
public keys. Pre-Shared Key (PSK) authentication SHALL NOT be used except for resumption. The 
full handshake in EAP-TLS with TLS 1.3 always provides forward secrecy by exchange of 
ephemeral "key_share" extensions in the ClientHello and ServerHello (e.g., containing Ephemeral 
Elliptic Curve Diffie-Hellman (ECDHE) public keys). SessionID is deprecated in TLS 1.3; see 
Sections 4.1.2 and 4.1.3 of [RFC8446]. TLS 1.3 introduced early application data that like all 
application data (other than the protected success indication described below) is not used in EAP- 
TLS; see Section 4.2.10 of [RFC8446] for additional information on the "early_data" extension. 
Resumption is handled as described in Section 2.1.3. As a protected success indication [RFC3748], 
the EAP-TLS server always sends TLS application data 0x00; see Section 2.5. Note that a TLS 
implementation MAY not allow the EAP-TLS layer to control in which order things are sent and 
the application data MAY therefore be sent before a NewSessionTicket. TLS application data 0x00 
is therefore to be interpreted as success after the EAP-Request that contains TLS application data 
0x00. After the EAP-TLS server has sent an EAP-Request containing the TLS application data 0x00 
and received an EAP-Response packet of EAP-Type=EAP-TLS and no data, the EAP-TLS server 
sends EAP-Success. 


Figure 1 shows an example message flow for a successful EAP-TLS full handshake with mutual 
authentication (and neither HelloRetryRequest nor post-handshake messages are sent). 


Preuß Mattsson & Sethi Standards Track Page 6 


RFC 9190 EAP-TLS 1.3 February 2022 


EAP-TLS Peer EAP-TLS Server 
EAP-Request/ 
cae mica a Identity 
EAP-Response/ 
Identity (Privacy-Friendly) -------- > 


EAP-Request/ 
EAP-Type=EAP-TLS 
<-------- (TLS Start) 
EAP-Response/ 
EAP-Type=EAP-TLS 
(TLS ClientHello) = 9 ===-=-=-=-- > 
EAP-Request/ 
EAP-Type=EAP-TLS 
(TLS ServerHello, 
TLS EncryptedExtensions, 
TLS CertificateRequest, 
TLS Certificate, 
TLS CertificateVerify, 
<-------- TLS Finished) 
EAP-Response/ 
EAP-Type=EAP-TLS 
(TLS Certificate, 
TLS CertificateVerify, 
TLS Finished) ==------ > 
EAP-Request/ 
EAP-Type=EAP-TLS 
<-------- (TLS Application Data 0x00) 
EAP-Response/ 
EAP-Type=EAP-TLS =-=- ---- > 
se EAP-Success 


Figure 1: EAP-TLS Mutual Authentication 


2.1.2. Ticket Establishment 


This is a new section when compared to [RFC5216]. 


To enable resumption when using EAP-TLS with TLS 1.3, the EAP-TLS server MUST send one or 
more post-handshake NewSessionTicket messages (each associated with a PSK, a PSK identity, a 
ticket lifetime, and other parameters) in the initial authentication. Note that TLS 1.3 [RFC8446] 
limits the ticket lifetime to a maximum of 604800 seconds (7 days) and EAP-TLS servers MUST 
respect this upper limit when issuing tickets. The NewSessionTicket is sent after the EAP-TLS 
server has received the client Finished message in the initial authentication. The 
NewSessionTicket can be sent in the same flight as the TLS server Finished or later. The PSK 
associated with the ticket depends on the client Finished and cannot be pre-computed (so as to be 
sent in the same flight as the TLS server Finished) in handshakes with client authentication. The 
NewSessionTicket message MUST NOT include an "early_data" extension. If the "early_data" 
extension is received, then it MUST be ignored. Servers should take into account that fewer 
NewSessionTickets will likely be needed in EAP-TLS than in the usual HTTPS connection scenario. 
In most cases, a single NewSessionTicket will be sufficient. A mechanism by which clients can 
specify the desired number of tickets needed for future connections is defined in [TICKET- 
REQUESTS]. 
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Figure 2 shows an example message flow for a successful EAP-TLS full handshake with mutual 
authentication and ticket establishment of a single ticket. 


EAP-TLS Peer EAP-TLS Server 
EAP-Request/ 
A rape Identity 
EAP-Response/ 
Identity (Privacy-Friendly) -------- > 


EAP-Request/ 
EAP-Type=EAP-TLS 
<-------- (TLS Start) 
EAP-Response/ 
EAP-Type=EAP-TLS 
(TLS ClientHello) 9 =------- > 
EAP-Request/ 
EAP-Type=EAP-TLS 
(TLS ServerHello, 
TLS EncryptedExtensions, 
TLS CertificateRequest, 
TLS Certificate, 
TLS CertificateVerify, 
<-------- TLS Finished) 
EAP-Response/ 
EAP-Type=EAP-TLS 
(TLS Certificate, 
TLS CertificateVerify, 
TLS Finished) === ===== > 
EAP-Request/ 
EAP-Type=EAP-TLS 
(TLS NewSessionTicket, 
<-------- (TLS Application Data 0x00) 
EAP-Response/ 
EAP-Type=EAP-TLS === =---- > 
BOSS Soe EAP-Success 


Figure 2: EAP-TLS Ticket Establishment 


2.1.3. Resumption 


This section updates Section 2.1.2 of [RFC5216] by amending it in accordance with the following 
discussion. 


EAP-TLS is typically used with client authentication and typically fragments the TLS flights into a 
large number of EAP-requests and EAP-responses. Resumption significantly reduces the number 
of round trips and enables the EAP-TLS server to omit database lookups needed during a full 
handshake with client authentication. TLS 1.3 replaces the session resumption mechanisms in 
earlier versions of TLS with a new PSK exchange. When EAP-TLS is used with TLS version 1.3, EAP- 
TLS SHALL use a resumption mechanism compatible with version 1.3 of TLS. 


For TLS 1.3, resumption is described in Section 2.2 of [RFC8446]. If the client has received a 
NewsSessionTicket message from the EAP-TLS server, the client can use the PSK identity associated 
with the ticket to negotiate the use of the associated PSK. If the EAP-TLS server accepts it, then the 
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resumed session has been deemed to be authenticated and securely associated with the prior 
authentication or resumption. It is up to the EAP-TLS peer to use resumption, but it is 
RECOMMENDED that the EAP-TLS peer use resumption if it has a valid ticket that has not been used 
before. It is left to the EAP-TLS server whether to accept resumption, but it is RECOMMENDED that 
the EAP-TLS server accept resumption if the ticket that was issued is still valid. However, the EAP- 
TLS server MAY choose to require a full handshake. In the case a full handshake is required, the 
negotiation proceeds as if the session was a new authentication, and the resumption attempt is 
ignored. The requirements of Sections 2.1.1 and 2.1.2 then apply in their entirety. As described in 
Appendix C.4 of [RFC8446], reuse of a ticket allows passive observers to correlate different 
connections. EAP-TLS peers and EAP-TLS servers SHOULD follow the client tracking preventions 
in Appendix C.4 of [RFC8446]. 


It is RECOMMENDED to use Network Access Identifiers (NAIs) with the same realm during 
resumption and the original full handshake. This requirement allows EAP packets to be routed to 
the same destination as the original full handshake. If this recommendation is not followed, 
resumption is likely impossible. When NAI reuse can be done without privacy implications, it is 
RECOMMENDED to use the same NAI in the resumption as was used in the original full handshake 
[RFC7542]. For example, the NAI @realm can safely be reused since it does not provide any 
specific information to associate a user's resumption attempt with the original full handshake. 
However, reusing the NAI P2ZIM2F+OEVAO21nNWg2bVpgNnU=@realm enables an on-path 
attacker to associate a resumption attempt with the original full handshake. The TLS PSK identity 
is typically derived by the TLS implementation and may be an opaque blob without a routable 
realm. The TLS PSK identity on its own is therefore unsuitable as an NAI in the Identity Response. 


Figure 3 shows an example message flow for a subsequent successful EAP-TLS resumption 
handshake where both sides authenticate via a PSK provisioned via an earlier NewSessionTicket 
and where the server provisions a single new ticket. 
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EAP-TLS Peer EAP-TLS Server 
EAP-Request/ 
cae mica a Identity 
EAP-Response/ 
Identity (Privacy-Friendly) -------- > 


EAP-Request/ 
EAP-Type=EAP-TLS 
<-------- (TLS Start) 
EAP-Response/ 
EAP-Type=EAP-TLS 
(TLS ClientHello 
+ pre_shared_key) = = 8 — -------- > 
EAP-Request/ 
EAP-Type=EAP-TLS 
(TLS ServerHello, 
TLS EncryptedExtensions, 
<-------- TLS Finished, 
TLS NewSessionTicket) 
EAP-Response/ 
EAP-Type=EAP-TLS 


(TLS Finished) ===-=---- E 
EAP-Request/ 
EAP-Type=EAP-TLS 
<-------- (TLS Application Data 0x00) 
EAP-Response/ 
EAP-Type=EAP-TLS = 2 -------- > 
eee ee EAP-Success 


Figure 3: EAP-TLS Resumption 


As specified in Section 2.2 of [RFC8446], the EAP-TLS peer SHOULD supply a "key_share" extension 
when attempting resumption, which allows the EAP-TLS server to potentially decline resumption 
and fall back to a full handshake. If the EAP-TLS peer did not supply a "key_share" extension when 
attempting resumption, the EAP-TLS server needs to send a HelloRetryRequest to signal that 
additional information is needed to complete the handshake, and the EAP-TLS peer needs to send 
a second ClientHello containing that information. Providing a "key_share" and using the 
"psk_dhe_ke" pre-shared key exchange mode is also important in order to limit the impact ofa 
key compromise. When using "psk_dhe_ke", TLS 1.3 provides forward secrecy meaning that 
compromise of the PSK used for resumption does not compromise any earlier connections. The 
"psk_dh_ke" key exchange mode MUST be used for resumption unless the deployment has a local 
requirement to allow configuration of other mechanisms. 


2.1.4. Termination 


This section updates Section 2.1.3 of [RFC5216] by amending it in accordance with the following 
discussion. 
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TLS 1.3 changes both the message flow and the handshake messages compared to earlier versions 
of TLS. Therefore, some normative text in Section 2.1.3 of [RFC5216] does not apply for TLS 1.3. The 
two paragraphs below replace the corresponding paragraphs in Section 2.1.3 of [RFC5216] when 
EAP-TLS is used with TLS 1.3. The other paragraphs in Section 2.1.3 of [RFC5216] still apply with the 
exception that SessionID is deprecated. 


If the EAP-TLS peer authenticates successfully, the EAP-TLS server MUST send an EAP-Request 
packet with EAP-Type=EAP-TLS containing TLS records conforming to the version of TLS used. 
The message flow ends with a protected success indication from the EAP-TLS server, followed 
by an EAP-Response packet of EAP-Type=EAP-TLS and no data from the EAP-TLS peer, followed 
by EAP-Success from the server. 


If the EAP-TLS server authenticates successfully, the EAP-TLS peer MUST send an EAP-Response 
message with EAP-Type=EAP-TLS containing TLS records conforming to the version of TLS 
used. 


Figures 4, 5, and 6 illustrate message flows in several cases where the EAP-TLS peer or EAP-TLS 
server sends a TLS Error alert message. In earlier versions of TLS, error alerts could be warnings 
or fatal. In TLS 1.3, error alerts are always fatal and the only alerts sent at warning level are 
"close_notify" and "user_canceled", both of which indicate that the connection is not going to 
continue normally; see [RFC8446]. 


In TLS 1.3 [RFC8446], error alerts are not mandatory to send after a fatal error condition. Failure 
to send TLS Error alerts means that the peer or server would have no way of determining what 
went wrong. EAP-TLS 1.3 strengthens this requirement. Whenever an implementation encounters 
a fatal error condition, it MUST send an appropriate TLS Error alert. 


Figure 4 shows an example message flow where the EAP-TLS server rejects the ClientHello with an 
error alert. The EAP-TLS server can also partly reject the ClientHello with a HelloRetryRequest; 
see Section 2.1.6. 
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EAP-TLS Peer 
< - ee ee ee 
EAP-Response/ 
Identity (Privacy-Friendly) -------- > 


EAP-Response/ 
EAP-Type=EAP-TLS 
(TLS ClientHello) 


EAP-Response/ 
EAP-Type=EAP-TLS 


Figure 4: EAP-TLS Server Rejection of ClientHello 


EAP-TLS Server 


EAP-Request/ 
Identity 


EAP-Request/ 
EAP-Type=EAP-TLS 
(TLS Start) 


EAP-Request/ 
EAP-Type=EAP-TLS 
(TLS Error Alert) 


EAP-Failure 


February 2022 


Figure 5 shows an example message flow where EAP-TLS server authentication is unsuccessful 


and the EAP-TLS peer sends a TLS Error alert. 


EAP-TLS Peer 


EAP-Response/ 
Identity (Privacy-Friendly) -------- > 


EAP-Response/ 
EAP-Type=EAP-TLS 
(TLS ClientHello) 


EAP-Response/ 
EAP-Type=EAP-TLS 
(TLS Error Alert) 


EAP-TLS Server 


EAP-Request/ 
Identity 


EAP-Request/ 
EAP-Type=EAP-TLS 
(TLS Start) 


EAP-Request/ 
EAP-Type=EAP-TLS 

(TLS ServerHello, 

TLS EncryptedExtensions, 
TLS CertificateRequest, 
TLS Certificate, 

TLS CertificateVerify, 
TLS Finished) 


EAP-Failure 


Figure 5: EAP-TLS Unsuccessful EAP-TLS Server Authentication 
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Figure 6 shows an example message flow where the EAP-TLS server authenticates to the EAP-TLS 
peer successfully, but the EAP-TLS peer fails to authenticate to the EAP-TLS server and the server 
sends a TLS Error alert. 


EAP-TLS Peer EAP-TLS Server 
EAP-Request/ 
ih os Identity 
EAP-Response/ 
Identity (Privacy-Friendly) -------- > 


EAP-Request/ 
EAP-Type=EAP-TLS 
<-------- (TLS Start) 
EAP-Response/ 
EAP-Type=EAP-TLS 
(TLS ClientHello) = 9 -------- > 
EAP-Request/ 
EAP-Type=EAP-TLS 
(TLS ServerHello, 
TLS EncryptedExtensions, 
TLS CertificateRequest, 
TLS Certificate, 
TLS CertificateVerify, 
<-------- TLS Finished) 
EAP-Response/ 
EAP-Type=EAP-TLS 
(TLS Certificate, 
TLS CertificateVerify, 
TLS Finished) ===----- > 
EAP-Request/ 
EAP-Type=EAP-TLS 
<-------- (TLS Error Alert) 
EAP-Response/ 
EAP-Type=EAP-TLS_ == > 
<la EAP-Failure 


Figure 6: EAP-TLS Unsuccessful Client Authentication 


2.1.5. No Peer Authentication 


This is a new section when compared to [RFC5216]. 


Figure 7 shows an example message flow for a successful EAP-TLS full handshake without peer 
authentication (e.g., emergency services, as described in [RFC7406]). 
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EAP-TLS Peer EAP-TLS Server 
EAP-Request/ 
cae mica a Identity 
EAP-Response/ 
Identity (Privacy-Friendly) -------- > 


EAP-Request/ 
EAP-Type=EAP-TLS 
ee eee (TLS Start) 
EAP-Response/ 
EAP-Type=EAP-TLS 
(TLS ClientHello) = 9 ===-=-=-=-- z 
EAP-Request/ 
EAP-Type=EAP-TLS 
(TLS ServerHello, 
TLS EncryptedExtensions, 
TLS Certificate, 
TLS CertificateVerify, 
a eee a TLS Finished) 
EAP-Response/ 
EAP-Type=EAP-TLS 
(HES Seana shie ds) see caKe g 
EAP-Request/ 
EAP-Type=EAP-TLS 
<-------- (TLS Application Data 0x00) 
EAP-Response/ 
EAP-Type=EAP-TLS 2 2 -------- > 
E EAP-Success 


Figure 7: EAP-TLS without Peer Authentication 


2.1.6. Hello Retry Request 


This is a new section when compared to [RFC5216]. 


As defined in TLS 1.3 [RFC8446], EAP-TLS servers can send a HelloRetryRequest message in 
response to a ClientHello if the EAP-TLS server finds an acceptable set of parameters but the 
initial ClientHello does not contain all the needed information to continue the handshake. One 
use case is if the EAP-TLS server does not support the groups in the "key_share" extension (or there 
is no "key_share" extension) but supports one of the groups in the "supported_groups" extension. 
In this case, the client should send a new ClientHello with a "key_share" that the EAP-TLS server 
supports. 


Figure 8 shows an example message flow for a successful EAP-TLS full handshake with mutual 
authentication and HelloRetryRequest. Note the extra round trip as a result of the 
HelloRetryRequest. 
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EAP-TLS Peer EAP-TLS Server 
EAP-Request/ 
cae mica a Identity 
EAP-Response/ 
Identity (Privacy-Friendly) -------- > 


EAP-Request/ 
EAP-Type=EAP-TLS 
<-------- (TLS Start) 
EAP-Response/ 
EAP-Type=EAP-TLS 
(TLS ClientHello) 9 ===-=--=-- > 
EAP-Request/ 
EAP-Type=EAP-TLS 
(TLS HelloRetryRequest) 


EAP-Response/ 
EAP-Type=EAP-TLS 
(TLS ClientHello) = = 9 ------=- > 
EAP-Request/ 
EAP-Type=EAP-TLS 
(TLS ServerHello, 
TLS EncryptedExtensions, 
TLS CertificateRequest, 
TLS Certificate, 
TLS CertificateVerify, 
TLS Finished) 
EAP-Response/ 
EAP-Type=EAP-TLS 
(TLS Certificate, 
TLS CertificateVerify, 


TLS Finished) = -=--===- E 
EAP-Request/ 
EAP-Type=EAP-TLS 
<-------- (TLS Application Data @x@@) 
EAP-Response/ 
EAP-Type=EAP-TLS = 2 2 -------- > 
eee EAP-Success 


Figure 8: EAP-TLS with Hello Retry Request 


2.1.7. Identity 


This is a new section when compared to [RFC5216]. 


It is RECOMMENDED to use anonymous NAIs [RFC7542] in the Identity Response as such identities 
are routable and privacy-friendly. While opaque blobs are allowed by [RFC3748], such identities 
are NOT RECOMMENDED as they are not routable and should only be considered in local 
deployments where the EAP-TLS peer, EAP authenticator, and EAP-TLS server all belong to the 
same network. Many client certificates contain an identity such as an email address, which is 
already in NAI format. When the client certificate contains an NAI as subject name or alternative 
subject name, an anonymous NAI SHOULD be derived from the NAI in the certificate; see Section 
2.1.8. More details on identities are described in Sections 2.1.3, 2.1.8, 2.2, and 5.8. 
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2.1.8. Privacy 


This section updates Section 2.1.4 of [RFC5216] by amending it in accordance with the following 
discussion. 


EAP-TLS 1.3 significantly improves privacy when compared to earlier versions of EAP-TLS. EAP- 
TLS 1.3 forbids cipher suites without confidentiality, which means that TLS 1.3 is always 
encrypting large parts of the TLS handshake including the certificate messages. 


EAP-TLS peer and server implementations supporting TLS 1.3 MUST support anonymous Network 
Access Identifiers (NAIs) (Section 2.4 of [RFC7542]). A client supporting TLS 1.3 MUST NOT send its 
username (or any other permanent identifiers) in cleartext in the Identity Response (or any 
message used instead of the Identity Response). Following [RFC7542], it is RECOMMENDED to omit 
the username (i.e., the NAI is @realm), but other constructions suchas a fixed username (e.g., 
anonymous@realm) or an encrypted username (e.g., 
xCZINCPTK5+7y81CrSYbPg+RKPE30TrYLn4AQc4AC2U=@realm) are allowed. Note that the NAI 
MUST be a UTF-8 string as defined by the grammar in Section 2.2 of [RFC7542]. 


The HelloRequest message used for privacy in EAP-TLS 1.2 does not exist in TLS 1.3 but as the 
certificate messages in TLS 1.3 are encrypted, there is no need to send an empty certificate_list 
and perform a second handshake for privacy (as needed by EAP-TLS with earlier versions of TLS). 
When EAP-TLS is used with TLS version 1.3, the EAP-TLS peer and EAP-TLS server SHALL follow the 
processing specified by version 1.3 of TLS. This means that the EAP-TLS peer only sends an empty 
certificate_list if it does not have an appropriate certificate to send, and the EAP-TLS server MAY 
treat an empty certificate_list as a terminal condition. 


EAP-TLS with TLS 1.3 is always used with privacy. This does not add any extra round trips and the 
message flow with privacy is just the normal message flow as shown in Figure 1. 


2.1.9. Fragmentation 


This section updates Section 2.1.5 of [RFC5216] by amending it in accordance with the following 
discussion. 


Including ContentType (1 byte), ProtocolVersion (2 bytes), and length (2 bytes) headers, a single 
TLS record may be up to 16645 octets in length. EAP-TLS fragmentation support is provided 
through addition of a flags octet within the EAP-Response and EAP-Request packets, as well as a 
(conditional) TLS Message Length field of four octets. Implementations MUST NOT set the L bit in 
unfragmented messages, but they MUST accept unfragmented messages with and without the L 
bit set. 


Some EAP implementations and access networks may limit the number of EAP packet exchanges 
that can be handled. To avoid fragmentation, it is RECOMMENDED to keep the sizes of EAP-TLS 
peer, EAP-TLS server, and trust anchor certificates small and the length of the certificate chains 
short. In addition, it is RECOMMENDED to use mechanisms that reduce the sizes of Certificate 
messages. For a detailed discussion on reducing message sizes to prevent fragmentation, see 
[RFC9191]. 
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2.2. Identity Verification 


This section replaces Section 2.2 of [RFC5216] with the following discussion. The guidance in this 
section is relevant for EAP-TLS in general (regardless of the underlying TLS version used). 


The EAP peer identity provided in the EAP-Response/Identity is not authenticated by EAP-TLS. 
Unauthenticated information MUST NOT be used for accounting purposes or to give 
authorization. The authenticator and the EAP-TLS server MAY examine the identity presented in 
EAP-Response/Identity for purposes such as routing and EAP method selection. EAP-TLS servers 
MAY reject conversations if the identity does not match their policy. Note that this also applies to 
resumption; see Sections 2.1.3, 5.6, and 5.7. 


The EAP server identity in the TLS server certificate is typically a fully qualified domain name 
(FQDN) in the SubjectAltName (SAN) extension. Since EAP-TLS deployments may use more than 
one EAP server, each with a different certificate, EAP peer implementations SHOULD allow for the 
configuration of one or more trusted root certificates (CA certificate) to authenticate the server 
certificate and one or more server names to match against the SubjectAltName (SAN) extension 
in the server certificate. If any of the configured names match any of the names in the SAN 
extension, then the name check passes. To simplify name matching, an EAP-TLS deployment can 
assign a name to represent an authorized EAP server and EAP Server certificates can include this 
name in the list of SANs for each certificate that represents an EAP-TLS server. If server name 
matching is not used, then it degrades the confidence that the EAP server with which it is 
interacting is authoritative for the given network. If name matching is not used with a public root 
CA, then effectively any server can obtain a certificate that will be trusted for EAP authentication 
by the peer. While this guidance to verify domain names is new, and was not mentioned in 
[RFC5216], it has been widely implemented in EAP-TLS peers. As such, it is believed that this 
section contains minimal new interoperability or implementation requirements on EAP-TLS 
peers and can be applied to earlier versions of TLS. 


The process of configuring a root CA certificate and a server name is non-trivial; therefore, 
automated methods of provisioning are RECOMMENDED. For example, the eduroam federation 
[RFC7593] provides a Configuration Assistant Tool (CAT) to automate the configuration process. 
In the absence of a trusted root CA certificate (user configured or system-wide), EAP peers MAY 
implement a trust on first use (TOFU) mechanism where the peer trusts and stores the server 
certificate during the first connection attempt. The EAP peer ensures that the server presents the 
same stored certificate on subsequent interactions. Use of a TOFU mechanism does not allow for 
the server certificate to change without out-of-band validation of the certificate and is therefore 
not suitable for many deployments including ones where multiple EAP servers are deployed for 
high availability. TOFU mechanisms increase the susceptibility to traffic interception attacks and 
should only be used if there are adequate controls in place to mitigate this risk. 


2.3. Key Hierarchy 


This section updates Section 2.3 of [RFC5216] by replacing it in accordance with the following 
discussion. 
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TLS 1.3 replaces the TLS pseudorandom function (PRF) used in earlier versions of TLS with the 
HMAC-based Key Derivation Function (HKDF) and completely changes the key schedule. The key 
hierarchies shown in Section 2.3 of [RFC5216] are therefore not correct when EAP-TLS is used with 
TLS version 1.3. For TLS 1.3 the key schedule is described in Section 7.1 of [RFC8446]. 


When EAP-TLS is used with TLS version 1.3, the Key_Material and Method-Id SHALL be derived 
from the exporter_secret using the TLS exporter interface [RFC5705] (for TLS 1.3, this is defined in 
Section 7.5 of [RFC8446]). Type is the value of the EAP Type field defined in Section 2 of [RFC3748]. 
For EAP-TLS, the Type field has value 0x0D. 


Type = @x@D 

Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", 
Type, 128) 

Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id", 
Type, 64) 

Session-Id = Type || Method-Id 


The MSK and EMSK are derived from the Key_Material in the same manner as with EAP-TLS 
[RFC5216], Section 2.3. The definitions are repeated below for simplicity: 


MSK 
EMSK 


Key_Material(@, 63) 
Key_Material(64, 127) 


Other TLS-based EAP methods can use the TLS exporter in a similar fashion; see [TLS-EAP-TYPES]. 


[RFC5247] deprecates the use of an Initialization Vector (IV). Thus, RECV-IV and SEND-IV are not 
exported in EAP-TLS with TLS 1.3. As noted in [RFC5247], lower layers use the MSK in a lower-layer- 
dependent manner. EAP-TLS with TLS 1.3 exports the MSK and does not specify how it is used by 
lower layers. 


Note that the key derivation MUST use the length values given above. While in TLS 1.2 and earlier 
it was possible to truncate the output by requesting less data from the TLS-Exporter function, this 
practice is not possible with TLS 1.3. If an implementation intends to use only a part of the output 
of the TLS-Exporter function, then it MUST ask for the full output and then only use the desired 
part. Failure to do so will result in incorrect values being calculated for the above keying material. 


By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation that provides a public API 
for the exporter. Note that when TLS 1.2 is used with the EAP-TLS exporter [RFC5705] it generates 
the same key material as in EAP-TLS [RFC5216]. 


2.4. Parameter Negotiation and Compliance Requirements 


This section updates Section 2.4 of [RFC5216] by amending it in accordance with the following 
discussion. 
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TLS 1.3 cipher suites are defined differently than in earlier versions of TLS (see Appendix B.4 of 
[RFC8446]), and the cipher suites discussed in Section 2.4 of [RFC5216] can therefore not be used 
when EAP-TLS is used with TLS version 1.3. 


When EAP-TLS is used with TLS version 1.3, the EAP-TLS peers and EAP-TLS servers MUST comply 
with the compliance requirements (mandatory-to-implement cipher suites, signature algorithms, 
key exchange algorithms, extensions, etc.) defined in Section 9 of [RFC8446]. In EAP-TLS with TLS 
1.3, only cipher suites with confidentiality SHALL be supported. 


While EAP-TLS does not protect any application data except for the 0x00 byte that serves as 
protected success indication, the negotiated cipher suites and algorithms MAY be used to secure 
data as done in other TLS-based EAP methods. 


2.5. EAP State Machines 


This is a new section when compared to [RFC5216] and only applies to TLS 1.3. [RFC4137] offers a 
proposed state machine for EAP. 


TLS 1.3 [RFC8446] introduces post-handshake messages. These post-handshake messages use the 
handshake content type and can be sent after the main handshake. Examples of post-handshake 
messages are NewSessionTicket, which is used for resumption and KeyUpdate, which is not useful 
and not expected in EAP-TLS. After sending TLS Finished, the EAP-TLS server may send any 
number of post-handshake messages in one or more EAP-Requests. 


To provide a protected success result indication and to decrease the uncertainty for the EAP-TLS 
peer, the following procedure MUST be followed: 


When an EAP-TLS server has successfully processed the TLS client Finished and sent its last 
handshake message (Finished or a post-handshake message), it sends an encrypted TLS record 
with application data 0x00. The encrypted TLS record with application data 0x00 is a protected 
success result indication, as defined in [RFC3748]. After sending an EAP-Request that contains the 
protected success result indication, the EAP-TLS server must not send any more EAP-Requests and 
may only send an EAP-Success. The EAP-TLS server MUST NOT send an encrypted TLS record with 
application data 0x00 before it has successfully processed the client Finished and sent its last 
handshake message. 


TLS Error alerts SHOULD be considered a failure result indication, as defined in [RFC3748]. 
Implementations following [RFC4137] set the alternate indication of failure variable altReject 
after sending or receiving an error alert. After sending or receiving a TLS Error alert, the EAP-TLS 
server may only send an EAP-Failure. Protected TLS Error alerts are protected failure result 
indications, and unprotected TLS Error alerts are not. 


The keying material can be derived after the TLS server Finished has been sent or received. 
Implementations following [RFC4137] can then set the eapKeyData and aaaEapKeyData 
variables. 
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The keying material can be made available to lower layers and the authenticator after the 
authenticated success result indication has been sent or received. Implementations following 
[RFC4137] can set the eapKeyAvailable and aaaEapKeyAvailable variables. 


3. Detailed Description of the EAP-TLS Protocol 


There are no updates to Section 3 of [RFC5216]. 


4. IANA Considerations 


This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding 
registration of values related to EAP-TLS 1.3 in accordance with [RFC8126]. 


Per this document, IANA has added the following labels to the "TLS Exporter Labels" registry 
defined by [RFC5705]. These labels are used in derivation of Key_Material and Method-Id as 
defined in Section 2.3: 


Value DTLS-OK Recommended Note 
EXPORTER_EAP_TLS_Key_Material N Y 
EXPORTER EAP TLS Method-Id N Y 


Table 1: TLS Exporter Labels 


5. Security Considerations 


The security considerations of TLS 1.3 [RFC8446] apply to EAP-TLS 1.3. 


5.1. Security Claims 


Using EAP-TLS with TLS 1.3 does not change the security claims for EAP-TLS as given in Section 5.1 
of [RFC5216]. However, it strengthens several of the claims as described in the following updates 
to the notes given in Section 5.1 of [RFC5216]. 


[1] Mutual authentication: By mandating revocation checking of certificates, the 
authentication in EAP-TLS with TLS 1.3 is stronger as authentication with revoked certificates 
will always fail. 


[2] Confidentiality: The TLS 1.3 handshake offers much better confidentiality than earlier 
versions of TLS. EAP-TLS with TLS 1.3 mandates use of cipher suites that ensure 
confidentiality. TLS 1.3 also encrypts certificates and some of the extensions. When using 
EAP-TLS with TLS 1.3, the use of privacy is mandatory and does not cause any additional 
round trips. 
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[3] Cryptographic strength: TLS 1.3 only defines strong algorithms without major weaknesses 
and EAP-TLS with TLS 1.3 always provides forward secrecy; see [RFC8446]. Weak algorithms 
such as 3DES, CBC mode, RC4, SHA-1, MD5, P-192, and RSA-1024 have not been registered for 
use in TLS 1.3. 


[4] Cryptographic negotiation: The TLS layer handles the negotiation of cryptographic 
parameters. When EAP-TLS is used with TLS 1.3, EAP-TLS inherits the cryptographic 
negotiation of the AEAD algorithm, HKDF hash algorithm, key exchange groups, and 
signature algorithm; see Section 4.1.1 of [RFC8446]. 


5.2. Peer and Server Identities 


No updates to Section 5.2 of [RFC5216]. Note that Section 2.2 has additional discussion on 
identities. 


5.3. Certificate Validation 


No updates to Section 5.3 of [RFC5216]. In addition to Section 5.3 of [RFC5216], guidance on server 
certificate validation can be found in [RFC6125]. 


5.4. Certificate Revocation 


This section updates Section 5.4 of [RFC5216] by amending it in accordance with the following 
discussion. 


There are a number of reasons (e.g., key compromise, CA compromise, privilege withdrawn, etc.) 
why EAP-TLS peer, EAP-TLS server, or sub-CA certificates have to be revoked before their expiry 
date. Revocation of the EAP-TLS server's certificate is complicated by the fact that the EAP-TLS 
peer may not have Internet connectivity until authentication completes. 


When EAP-TLS is used with TLS 1.3, the revocation status of all the certificates in the certificate 
chains MUST be checked (except the trust anchor). An implementation may use the Certificate 
Revocation List (CRL), Online Certificate Status Protocol (OSCP), or other standardized/ 
proprietary methods for revocation checking. Examples of proprietary methods are non- 
standard formats for distribution of revocation lists as well as certificates with very short 
lifetime. 


EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status Requests (OCSP stapling) as 
specified in [RFC6066] and Section 4.4.2.1 of [RFC8446]. It is RECOMMENDED that EAP-TLS peers and 
EAP-TLS servers use OCSP stapling for verifying the status of the EAP-TLS server's certificate 
chain. When an EAP-TLS peer uses Certificate Status Requests to check the revocation status of 
the EAP-TLS server's certificate chain, it MUST treat a CertificateEntry (but not the trust anchor) 
without a valid CertificateStatus extension as invalid and abort the handshake with an 
appropriate alert. The OCSP status handling in TLS 1.3 is different from earlier versions of TLS; see 
Section 4.4.2.1 of [RFC8446]. In TLS 1.3, the OCSP information is carried in the CertificateEntry 
containing the associated certificate instead of a separate CertificateStatus message as in 
[RFC6066]. This enables sending OCSP information for all certificates in the certificate chain 
(except the trust anchor). 
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To enable revocation checking in situations where EAP-TLS peers do not implement or use OCSP 
stapling, and where network connectivity is not available prior to authentication completion, 
EAP-TLS peer implementations MUST also support checking for certificate revocation after 
authentication completes and network connectivity is available. An EAP peer implementation 
SHOULD NOT trust the network (and any services) until it has verified the revocation status of the 
server certificate after receiving network connectivity. An EAP peer MUST use a secure transport 
to verify the revocation status of the server certificate. An EAP peer SHOULD NOT send any other 
traffic before revocation checking for the server certificate is complete. 


5.5. Packet Modification Attacks 


This section updates Section 5.5 of [RFC5216] by amending it in accordance with the following 
discussion. 


As described in [RFC3748] and Section 5.5 of [RFC5216], the only information that is integrity and 
replay protected in EAP-TLS are the parts of the TLS Data that TLS protects. All other information 
in the EAP-TLS message exchange including EAP-Request and EAP-Response headers, the identity 
in the Identity Response, EAP-TLS packet header fields, Type, Flags, EAP-Success, and EAP-Failure 
can be modified, spoofed, or replayed. 


Protected TLS Error alerts are protected failure result indications and enable the EAP-TLS peer 
and EAP-TLS server to determine that the failure result was not spoofed by an attacker. Protected 
failure result indications provide integrity and replay protection but MAY be unauthenticated. 
Protected failure results do not significantly improve availability as TLS 1.3 treats most 
malformed data as a fatal error. 


5.6. Authorization 


This is a new section when compared to [RFC5216]. The guidance in this section is relevant for 
EAP-TLS in general (regardless of the underlying TLS version used). 


EAP servers will usually require the EAP peer to provide a valid certificate and will fail the 
connection if one is not provided. Some deployments may permit no peer authentication for 
some or all connections. When peer authentication is not used, EAP-TLS server implementations 
MUST take care to limit network access appropriately for unauthenticated peers, and 
implementations MUST use resumption with caution to ensure that a resumed session is not 
granted more privilege than was intended for the original session. An example of limiting 
network access would be to invoke a vendor's walled garden or quarantine network 
functionality. 


EAP-TLS is typically encapsulated in other protocols such as PPP [RFC1661], RADIUS [RFC2865], 
Diameter [RFC6733], or the Protocol for Carrying Authentication for Network Access (PANA) 
[RFC5191]. The encapsulating protocols can also provide additional, non-EAP information to an 
EAP-TLS server. This information can include, but is not limited to, information about the 
authenticator, information about the EAP-TLS peer, or information about the protocol layers 
above or below EAP (MAC addresses, IP addresses, port numbers, Wi-Fi Service Set Identifiers 
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(SSIDs), etc.). EAP-TLS servers implementing EAP-TLS inside those protocols can make policy 
decisions and enforce authorization based on a combination of information from the EAP-TLS 
exchange and non-EAP information. 


As noted in Section 2.2, the identity presented in EAP-Response/Identity is not authenticated by 
EAP-TLS and is therefore trivial for an attacker to forge, modify, or replay. Authorization and 
accounting MUST be based on authenticated information such as information in the certificate or 
the PSK identity and cached data provisioned for resumption as described in Section 5.7. Note 
that the requirements for Network Access Identifiers (NAIs) specified in Section 4 of [RFC7542] 
still apply and MUST be followed. 


EAP-TLS servers MAY reject conversations based on non-EAP information provided by the 
encapsulating protocol, for example if the MAC address of the authenticator does not match the 
expected policy. 


In addition to allowing configuration of one or more trusted root certificates (CA certificate) to 
authenticate the server certificate and one or more server names to match against the 
SubjectAltName (SAN) extension, EAP peer implementations MAY allow binding the configured 
acceptable SAN to a specific CA (or CAs) that should have issued the server certificate to prevent 
attacks from rogue or compromised CAs. 


5.7. Resumption 


This is a new section when compared to [RFC5216]. The guidance in this section is relevant for 
EAP-TLS in general (regardless of the underlying TLS version used). 


There are a number of security issues related to resumption that are not described in [RFC5216]. 
The problems, guidelines, and requirements in this section therefore apply to EAP-TLS when it is 
used with any version of TLS. 


When resumption occurs, it is based on cached information at the TLS layer. To perform 
resumption securely, the EAP-TLS peer and EAP-TLS server need to be able to securely retrieve 
authorization information such as certificate chains from the initial full handshake. This 
document uses the term "cached data" to describe such information. Authorization during 
resumption MUST be based on such cached data. The EAP-TLS peer and EAP-TLS server MAY 
perform fresh revocation checks on the cached certificate data. Any security policies for 
authorization MUST be followed also for resumption. The certificates may have been revoked 
since the initial full handshake and the authorizations of the other party may have been reduced. 
If the cached revocation data is not sufficiently current, the EAP-TLS peer or EAP-TLS server MAY 
force a full TLS handshake. 


There are two ways to retrieve the cached data from the original full handshake. The first method 
is that the EAP-TLS server and client cache the information locally. The cached information is 
identified by an identifier. For TLS versions before 1.3, the identifier can be the session ID; for TLS 
1.3, the identifier is the PSK identity. The second method for retrieving cached information is via 
[RFC5077] or [RFC8446], where the EAP-TLS server avoids storing information locally and instead 
encapsulates the information into a ticket that is sent to the client for storage. This ticket is 
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encrypted using a key that only the EAP-TLS server knows. Note that the client still needs to cache 
the original handshake information locally and will obtain it while determining the session ID or 
PSK identity to use for resumption. However, the EAP-TLS server is able to decrypt the ticket or 
PSK to obtain the original handshake information. 


The EAP-TLS server or EAP client MUST cache data during the initial full handshake sufficient to 
allow authorization decisions to be made during resumption. If cached data cannot be retrieved 
securely, resumption MUST NOT be done. 


The above requirements also apply if the EAP-TLS server expects some system to perform 
accounting for the session. Since accounting must be tied to an authenticated identity, and 
resumption does not supply such an identity, accounting is impossible without access to cached 
data. Therefore, systems that expect to perform accounting for the session SHOULD cache an 
identifier that can be used in subsequent accounting. 


As suggested in [RFC8446], EAP-TLS peers MUST NOT store resumption PSKs or tickets (and 
associated cached data) for longer than 604800 seconds (7 days) regardless of the PSK or ticket 
lifetime. The EAP-TLS peer MAY delete them earlier based on local policy. The cached data MAY 
also be removed on the EAP-TLS server or EAP-TLS peer if any certificate in the certificate chain 
has been revoked or has expired. In all such cases, an attempt at resumption results in a full TLS 
handshake instead. 


Information from the EAP-TLS exchange (e.g., the identity provided in EAP-Response/Identity) as 
well as non-EAP information (e.g., IP addresses) may change between the initial full handshake 
and resumption. This change creates a "time-of-check time-of-use" (TOCTOU) security 
vulnerability. A malicious or compromised user could supply one set of data during the initial 
authentication, and a different set of data during resumption, potentially allowing them to obtain 
access that they should not have. 


If any authorization, accounting, or policy decisions were made with information that has 
changed between the initial full handshake and resumption, and if change may lead to a different 
decision, such decisions MUST be reevaluated. It is RECOMMENDED that authorization, accounting, 
and policy decisions are reevaluated based on the information given in the resumption. EAP-TLS 
servers MAY reject resumption where the information supplied during resumption does not 
match the information supplied during the original authentication. If a safe decision is not 
possible, EAP-TLS servers SHOULD reject the resumption and continue with a full handshake. 


Sections 2.2 and 4.2.11 of [RFC8446] provide security considerations for TLS 1.3 resumption. 


5.8. Privacy Considerations 


This is a new section when compared to [RFC5216]. 


TLS 1.3 offers much better privacy than earlier versions of TLS as discussed in Section 2.1.8. In this 
section, we only discuss the privacy properties of EAP-TLS with TLS 1.3. For privacy properties of 
TLS 1.3 itself, see [RFC8446]. 
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EAP-TLS sends the standard TLS 1.3 handshake messages encapsulated in EAP packets. 
Additionally, the EAP-TLS peer sends an identity in the first EAP-Response. The other fields in the 
EAP-TLS Request and the EAP-TLS Response packets do not contain any cleartext privacy- 
sensitive information. 


Tracking of users by eavesdropping on Identity Responses or certificates is a well-known 
problem in many EAP methods. When EAP-TLS is used with TLS 1.3, all certificates are encrypted, 
and the username part of the Identity Response is not revealed (e.g., using anonymous NAIs). 
Note that even though all certificates are encrypted, the server's identity is only protected against 
passive attackers while the client's identity is protected against both passive and active attackers. 
As with other EAP methods, even when privacy-friendly identifiers or EAP tunneling is used, the 
domain name (i.e., the realm) in the NAT is still typically visible. How much privacy-sensitive 
information the domain name leaks is highly dependent on how many other users are using the 
same domain name in the particular access network. If all EAP-TLS peers have the same domain, 
no additional information is leaked. If a domain name is used by a small subset of the EAP-TLS 
peers, it may aid an attacker in tracking or identifying the user. 


Without padding, information about the size of the client certificate is leaked from the size of the 
EAP-TLS packets. The EAP-TLS packets sizes may therefore leak information that can be used to 
track or identify the user. If all client certificates have the same length, no information is leaked. 
EAP-TLS peers SHOULD use record padding; see Section 5.4 of [RFC8446] to reduce information 
leakage of certificate sizes. 


If anonymous NAIs are not used, the privacy-friendly identifiers need to be generated with care. 
The identities MUST be generated in a cryptographically secure way so that it is computationally 
infeasible for an attacker to differentiate two identities belonging to the same user from two 
identities belonging to different users in the same realm. This can be achieved, for instance, by 
using random or pseudo-random usernames such as random byte strings or ciphertexts and only 
using the pseudo-random usernames a single time. Note that the privacy-friendly usernames also 
MUST NOT include substrings that can be used to relate the identity to a specific user. Similarly, 
privacy-friendly usernames MUST NOT be formed by a fixed mapping that stays the same across 
multiple different authentications. 


An EAP-TLS peer with a policy allowing communication with EAP-TLS servers supporting only TLS 
1.2 without privacy and witha static RSA key exchange is vulnerable to disclosure of the EAP-TLS 
peer username. An active attacker can in this case make the EAP-TLS peer believe that an EAP- 
TLS server supporting TLS 1.3 only supports TLS 1.2 without privacy. The attacker can simply 
impersonate the EAP-TLS server and negotiate TLS 1.2 with static RSA key exchange and send a 
TLS alert message when the EAP-TLS peer tries to use privacy by sending an empty certificate 
message. Since the attacker (impersonating the EAP-TLS server) does not provide a proof-of- 
possession of the private key until the Finished message when a static RSA key exchange is used, 
an EAP-TLS peer may inadvertently disclose its identity (username) to an attacker. Therefore, it is 
RECOMMENDED for EAP-TLS peers to not use EAP-TLS with TLS 1.2 and static RSA-based cipher 
suites without privacy. This implies that an EAP-TLS peer SHOULD NOT continue the EAP 
authentication attempt if a TLS 1.2 EAP-TLS server sends an EAP-TLS/Request with a TLS alert 
message in response to an empty certificate message from the peer. 
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5.9. Pervasive Monitoring 


This is a new section when compared to [RFC5216]. 


Pervasive monitoring refers to widespread surveillance of users. In the context of EAP-TLS, 
pervasive monitoring attacks can target EAP-TLS peer devices for tracking them (and their users) 
when they join a network. By encrypting more information, mandating the use of privacy, and 
always providing forward secrecy, EAP-TLS with TLS 1.3 offers much better protection against 
pervasive monitoring. In addition to the privacy attacks discussed above, surveillance on a large 
scale may enable tracking of a user over a wide geographical area and across different access 
networks. Using information from EAP-TLS together with information gathered from other 
protocols increases the risk of identifying individual users. 


In TLS 1.3, the post-handshake key update mechanism provides forward secrecy for the traffic 
secrets. EAP-TLS 1.3 does not provide a similar mechanism for MSK and EMSK. Implementation 
using the exported MSK and EMSK can achieve forward secrecy by frequently deriving new keys 
in a similar way as described in Section 7.2 of [RFC8446]. 


5.10. Discovered Vulnerabilities 


This is a new section when compared to [RFC5216]. 


Over the years, there have been several serious attacks on earlier versions of Transport Layer 
Security (TLS), including attacks on its most commonly used ciphers and modes of operation. 
[RFC7457] summarizes the attacks that were known at the time of publishing, and BCP 195 
[RFC7525] [RFC8996] provides recommendations and requirements for improving the security of 
deployed services that use TLS. However, many of the attacks are less serious for EAP-TLS as EAP- 
TLS only uses the TLS handshake and does not protect any application data. EAP-TLS 
implementations MUST mitigate known attacks. EAP-TLS implementations need to monitor and 
follow new EAP- and TLS-related security guidance and requirements such as [RFC8447] and 
[RFC9155]. 


5.11. Cross-Protocol Attacks 


This is a newsection when compared to [RFC5216]. 


Allowing the same certificate to be used in multiple protocols can potentially allow an attacker to 
authenticate via one protocol and then "resume" that session in another protocol. Section 2.2 
suggests that certificates typically have one or more FQDNSs in the SAN extension. However, those 
fields are for EAP validation only and do not indicate that the certificates are suitable for use with 
HTTPS or other protocols on the named host. 
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Section 2.1.3 suggests that authorization rules should be reapplied on resumption but does not 
mandate this behavior. As a result, this cross-protocol resumption could allow the attacker to 
bypass authorization policies and to obtain undesired access to secured systems. Along with 
making sure that appropriate authorization information is available and used during 
resumption, using different certificates and resumption caches for different protocols is 
RECOMMENDED to help keep different protocol usages separate. 
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Appendix A. Updated References 


The following references in [RFC5216] are updated as specified below when EAP-TLS is used with 
TLS 1.3. 


e All references to [RFC2560] are updated to refer to [RFC6960]. 
¢ All references to [RFC3280] are updated to refer to [RFC5280]. References to Section 4.2.1.13 of 
[RFC3280] are updated to refer to Section 4.2.1.12 of [RFC5280]. 


e All references to [RFC4282] are updated to refer to [RFC7542]. References to Section 2.1 of 
[RFC4282] are updated to refer to Section 2.2 of [RFC7542]. 


Acknowledgments 


The authors want to thank Bernard Aboba, Jari Arkko, Terry Burton, Alan DeKok, Ari Keränen, 
Benjamin Kaduk, Jouni Malinen, Oleg Pekar, Eric Rescorla, Jim Schaad, Joseph Salowey, Martin 
Thomson, Vesa Torvinen, Hannes Tschofenig, and Heikki Vatiainen for comments and 
suggestions on this document. Special thanks to the Document Shepherd Joseph Salowey. 


Contributors 


Alan DeKok, FreeRADIUS 


Authors' Addresses 


John Preuf§ Mattsson 

Ericsson 

SE-164 40 Kista 

Sweden 

Email: john.mattsson@ericsson.com 


Mohit Sethi 
Ericsson 

FI-02420 Jorvas 
Finland 

Email: mohit@ikifi 


Preuß Mattsson & Sethi Standards Track Page 31 


